A large number of applications require high speed, real time access to large databases with response time requirements of only a few milliseconds to tens of milliseconds. These applications (e.g., call routing in telecommunication systems, internet name and data services, financial applications, automation control, etc.) cannot afford the performance latency of accessing data that is disk-resident or ships the data through interprocess communications. These applications also cannot afford the memory requirements of mapping or caching the data in each client application's process virtual address space. These applications often cannot be hosted on a single machine due to reliability and performance constraints.
Traditional relational database architectures and client-server database systems often use a database server process. The client applications ship queries and other database operations to the database server which processes the requests (e.g., SQL standard query language operations) and returns the results.
The vast majority of object-oriented client-server database systems are typically based on a data-shipping approach. Data items (in the form of pages or objects) are shipped from the database server to clients so that the query processing and application processing can be performed through programmatic interfaces that support navigation.
All client/server database systems incur the overhead of interprocess or network communications and the overhead of caching and accessing the data in pageable process virtual address space.
Objects in an object-orient database contain references to other objects. Usually, the on-disk representation of an object differs from the in-memory representation of the object because of the way the storage manager treats inter-object references. Some systems use object identifiers (OIDs) for both the in-memory and on-disk representations. Other systems use virtual memory pointers or addresses for both representations. Finally, there are systems that use OIDs for the on-disk representation and virtual memory pointers for the in-memory representation. These systems convert the OIDs to virtual memory pointers or addresses when they fetch the objects from disk. This is referred to as swizzling. Object-oriented databases that do not perform pointer swizzling, use the unique object identifier (OID) to lookup the actual memory location of an object whenever the OID is dereferenced. The lookup process generally involves a relatively expensive search of an in-memory table that must be performed on every object reference.
Object oriented databases generally supply the following functions to the application program: 1) The ability to lookup and maintain navigational entry points into the database. These entry points are called root; 2) The ability to open one or more databases; 3) The ability to allocate and free memory from the persistent heap; and 4) The ability to navigate through object references. In addition a persistent store object oriented database often allows C++ interfaces, query languages, database utilities and the ability to store meta-data in the database.